Method and apparatus for communication and collaboration in an educational environment

ABSTRACT

A system and associated methods are provided for communication and collaboration in an educational environment. Integrated modules are provided for discussions, document sharing, photo sharing, events and invitations, and sign-ups. The system comprises a database adapted to allow dynamic formation of groups associated with activities or courses and notification of members of those groups regarding posting of information.

CROSS REFERENCE TO RELATED APPLICATION

This application claims the benefit of priority from U.S. ProvisionalPatent Application 61/879,697, filed Sep. 19, 2013.

BACKGROUND OF THE INVENTION

The present invention relates generally to systems and methods forfacilitating communications and information sharing for an educationalenvironment such as an elementary school.

Educational environments present unique communications issues. There isa constant need for communication not only between teachers and parents,but also amongst parents. Year-by-year, or semester-by-semester,enrollment changes lead to significant changes in which parties need toshare information with which other parties. Furthermore, variousactivities, such as parent-teach conferences, field trips, fairs, clubs,fund-raising events, sports teams, and parties, each present their ownunique communications needs.

Conventional means for addressing these problems have included school orclass newsletters, photo sharing web sites, email communication, paperforms, school directories, parent sign-up sheets, school announcementemails, and volunteer sign-up sheets. These conventional communicationssolutions fail to efficiently address the problems of educationalcommunication. Emails are hard to organize and search. Papercommunication is hard to manage, costly, and not green. Web sitesgenerally manage only discrete portions of the needed information andare hard to manage and organize Furthermore, replicating class lists,keeping them synchronized, and creating logins across multiple servicesis a time-consuming nuisance.

What is needed is an integrated and interactive platform that supportsthe needs of both parents and teachers, allowing effective and efficientmanagement of students' activities and enables communication,collaboration, sharing and organization among parents and betweenteachers and parents.

BRIEF SUMMARY OF THE INVENTION

A system and associated methods are provided for communication andcollaboration in an educational environment. Integrated modules areprovided for discussions, document sharing, photo sharing, events andinvitations, and sign-ups. The system comprises a database adapted toallow dynamic formation of groups associated with activities or coursesand notification of members of those groups regarding posting ofinformation

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing summary, as well as the following detailed description ofpreferred embodiments of the invention, will be better understood whenread in conjunction with the appended drawings. For the purpose ofillustrating the invention, there are shown in the drawings embodimentsthat are presently preferred. It should be understood, however, that theinvention is not limited to the precise arrangements andinstrumentalities shown.

FIG. 1 is an exemplary system diagram of the communication andcollaboration system;

FIG. 2 is an exemplary entity relationship diagram for a database designof a communication and collaboration system of FIG. 1;

FIG. 3 is an exemplary login screen for a communication andcollaboration system of FIG. 1;

FIG. 4 is a calendar interface of a communication and collaborationsystem of FIG. 1;

FIGS. 5-7 are examples of user interface screens related to informationsharing using a communication and collaboration system of FIG. 1; and

FIGS. 8-14 are examples of user interface screens related to the processof registering for classes using a communication and collaborationsystem of FIG. 1.

DETAILED DESCRIPTION OF THE INVENTION

Certain terminology is used in the following description for convenienceonly and is not limiting. The words “lower,” “bottom,” “top” and “upper”designate directions in the drawings to which reference is made. Theterminology includes the above-listed words, derivatives thereof, andwords of similar import. Additionally, the words “a” and “an”, as usedin the claims and in the corresponding portions of the specification,mean “at least one.”

Referring to the drawings in detail, wherein like reference numeralsindicate like elements throughout, a preferred communication andcollaboration system 100 for transmitting messages between and amongstteachers, parents, and students is described.

The system provides a platform for parents and teachers to communicate,collaborate, share, organize and plan for their children's schoolactivities. Among other advantages, the system allows parents to moreeasily manage their involvement at school and the activities of theirchildren.

The system provides an integrated and interactive platform that allowsparents effectively and efficiently manage their children's activitiesand their school involvement and streamlines communication,collaboration, sharing and organization among parents and betweenteachers and parents. The system provides unique tools for parentsand/or teachers including signup, invitation, photo sharing, discussion,and document sharing within classrooms or the school. Different levelsof group activities are aggregated, including school activities,classroom activities and private group activities. Teachers can publishschool/classroom notes to multiple classrooms. School calendar,group/classroom calendar, private group calendar and personal calendarin a centralized calendar view, or overlay.

Examples of school activities include book fairs, ice cream socials,clubs, plays, and sports practices, parent-teacher conferences,projects, class photos, and volunteer opportunities. Private activitiesmay include birthday parties, carpools, play dates, and study groups.Signups, invitations, discussions, document sharing, photo sharing, andcalendar functions are integrated in the system around activities.

The system provides the advantage of allowing a parent to manage schoolactivities of all of his or her children in a single place, despite thechildren being in different schools and in different after-schoolactivities. The system may also allow management of personal eventsalong-side school-related events.

Over time, parents may view the history of their children's involvementin their schools. Records of activities, including photos of activitiesand discussions, may be preserved long after a child has ended his orher affiliation with the school.

Referring to FIG. 1, the communication and collaboration system 100communicates over a network 190 with parent computers 110, teachercomputers 112, and administrator computers 114. Parent computers 110,teacher computers 112, and administrator computers 114 may be any sortof computing device, such as a desktop computer, laptop, tablet, mobilephone, or kiosk.

The system 100 may be implemented using one or more compute platforms.Certain functions, such as database and web serving, may be allocated toone or more separate physical or virtual machines and/or load-balanced.Program code for the system may be implemented in one or more languages.User interface elements may be stored or generated dynamically andtransmitted at least in part preferably in a markup language such asHTML. Network 190 may comprise various wired or wireless LANs, WANs,cellular networks, and the Internet. Users may preferably connect to thesystem via the Internet from a web browser. One or more hard drives orarrays of hard drives may be used to store program code and data. One ormore processors may execute program code associated with the system.

FIG. 2 is an example of a portion of an entity relationship diagramassociated with a database of communication and collaboration system100. Aspects of the entities stored within the database and theassociated system functionality are described below.

In a preferred embodiment, a split schema design is utilized for storageof system data. User, group, and school information may be stored in arelational database, while activities and related entities may be storedin a NoSQL database (e.g., Hadoop Database or HBase). Additionally,large data items, such as attachment documents or photos, may be storedin a separate third-party storage system, such as Amazon S3.

Entities School

The communication and collaboration system may manage communications formultiple schools over multiple school years. In a preferred embodiment,each school is represented by a row in a “school” table 202. Each schoolrecord in the school table 202 preferably comprises information such asan ID, name, description, link to a logo, address data, web siteinformation, status, a time the school was created, identifyinginformation such as an NCES ID, and the user ID of the creator of theschool record. A school entity may be considered a special form of thegroup entity described below, or a school may have a default grouprepresenting the entirety of the school.

A school may have one or more school administrators. Schooladministrators may be recorded in a “schooladmin” table 204. Each row ofthe table comprises a school ID and a user ID.

Users are invited to be associated with a school. Invitations aremanaged via a “schoolinvitation” table 206. Each row of the table maycomprise the email address of the invited party, the school ID, theschool year ID for which the invitation is relevant, and ID of the userinitiating the invitation, an indicator of the role to which the user isinvited to participate, an access token, a creation time for theinvitation, and a default group. Rows of the table may be preferablyremoved as invitations are accepted.

The access token may be included in the invitation and serve as ashorthand method of indicating the invitation in question when the userresponds. For instance, the access token may be provided as a part of aURL provided to the user in an email with the invitation.

Users associated with the school may be managed via a “schooluser” table208. Each row of the table may comprise a school ID, a user ID, the IDof a school year, a status indicator, a role indicator for the userrelative to that school, and an indicator of the user's last accesstime.

A “course” table 214 comprises records for each course. A “courseregistration” table 216 comprises information regarding the relationshipbetween users and courses.

Much of the data in the system is organized around the concept of aschool year. This reflects the real-world fact that many affiliations ina school, such as class membership and group membership, are assigned ona year-by-year basis. A “schoolyear” table 210 may be used to recordinformation regarding each school year. Each row may comprise a schoolId, a school Year ID, a code, and start and end dates for the schoolyear. The school year ID may preferably be the four-digit calendar yearof the year in which the school year ends. The school year ID may beused in other data entities to represent the association with the schoolyear.

When a class is added to a school, it is associated with a school year.A default class activity may be automatically created for the schoolyear. An associated entry in a SchoolGroup table 212 may have aschoolYear field to provide this correlation.

Once a school year is completed, data related to the school year, suchas information related to activities and groups, may be archived.Read-only access may preferably be provided to the data from past schoolyears.

When a school year is archived, each associated course or class ismarked as closed. In such condition, no person can join or leave theclass. Upon archive, all activities associated with the school year willbe put under read-only mode. Associated users may go back and review orsearch existing content, discussions, photos, etc., but cannot add orupdate data.

Data from a school profile may be carried over to subsequent schoolyears. The administrator may only need to edit start and end dates toestablish the new school year. All existing users may be automaticallymoved to next school year, and would then need to join new classes forthe new year. Alternatively, all prior users may be invited to join thenew school year or users for the new school year may be loaded from adata source such as a school directory spreadsheet.

School/Class Invitations

Invitations may be issued via the upload of a spreadsheet with parentname, student name, parent address, etc. Using this method, the user maybe invited to the school and/or class, and also added to a schooldirectory tab. The user may also be invited to a school or class viaemail. The system may preferably provide a function to allow theadministrator to invite all users from a previous school year.

Users

A “user” table 220 may be used to store information regarding users ofthe system. Each row of the table may comprise an ID for the user, anemail address, first and last names, a middle initial, a status, apassword, an indicator of the user's role, a creation time for the useraccount, and an alternative email address. In a preferred embodiment,the role in the user table relates to the user's role relative to thesystem, such as administrator versus user, rather than the user's rolein relation to a school.

User Signup

A “usersignup” table 222 may be used to manage user signups. Each rowmay comprise an ID of the user engaging in the signup, an ID of thesignup item, a quantity, where appropriate, an ID of the user assigningtasks or items, an ID for the event for which signup is being performed,a creation time for the user signup entry, and an email address.

The use of an email address in user signup allows for situations inwhich a person being invited for signup may not yet have a user accounton the system. Thus, the system may allow lists for signup or invitationto include registered as well as non-registered users. For known users,the system may pre-populate or not ask for email addresses.

In a preferred embodiment, if a user does not yet have an account withthe system and received a signup notification, the system may force theuser to register before completing the sign up process. In the case ofinvitations, however, the user may be allowed to accept the invitationwithout registering.

User Profile (Key is User Id)

The system may store additional information related to the user. Forinstance, a “userprofile” table 224 may store additional informationabout the user not contained in the “user” table, such as a mapping toavatar data.

User Roles

In a preferred embodiment, a user is assigned one of three roles:administrator, parent, or teacher. A user with the Parent role can joinor leave a school if invited or if he or she pays the membership fee. AParent may also join or leave classrooms within the school, and canmanage private groups as an owner. A user with the Teacher role maycreate and publish school/classroom notes and perform all functions ofthe Parent role. A user with the Administrator role may be a schoolstaff member or a designated PTA/PTO member. Administrators are allowedto set up classrooms, invite parents to join the site, manage users androles, create and manage school level announcements, forms, activities,and calendars, and perform all functions allowed in the Teacher andParent roles.

In a preferred embodiment, students themselves are not users. Eachregistered parent user may have zero or more students, and the parentwill be a “member” of all his/her students' classes. Each classregistration sheet will show which students are in the class.

A “forgotpassword” table 240 may be used to manage data related topassword recovery. Each row may comprise a token, a user ID, and arequest time.

Groups

Users may be organized into groups. In a preferred embodiment, a classor course is represented as a group.

A “group” table 250 may be used to manage data related to groups. Eachrow may comprise a group ID, a group name, a group description, a grouptype, a status, a creation time, a user ID of the creator of the group,an ID of the school to which the group is associated, and a school yearto which the group is associated.

Users may be invited to join groups through an invitation process. A“groupinvitation” table 252 may be used to store data related toinvitations to groups. Each row may comprise an email address of theinvited party, an ID for the group, a user ID of the person initiatingthe invitation, a role, an access token, a creation time, a name, and auser ID.

Notes related to a group may be stored in a “groupnote” table 254. Eachrow may comprise the ID of the user creating the note, the ID of thegroup to which the note is associated, and an announcement ID.

The association of users with groups may be recorded in a “groupuser”table 256. Each row of the table may comprise a user ID, the ID of thegroup, a status of the group membership, a role for the user relative tothe group, and a type.

Activities

Activities are a core feature of the system and a central focus of thedesign. In a preferred embodiment, activities of each type may beassociated with discussions, attachments, photo sharing, signups, andinvitations. Since information is organized in an activity-centricmanner, the system provides a significant usability advantage over theuser of separate single-task sites for photos, calendars, and signups,where the information is necessarily organized by the type ofinformation. By accessing a page for an activity, the user may beprovided with all of the available information for that activity with asingle site login.

A group or school may have one or more activities. An “activity” table260 may be used to record information about these activities. Each rowof the table may comprise a title, a description, an event type, and auser ID of the user creating the activity.

In a preferred embodiment, three different activity types areprovided: 1) School activity, 2) Class or course activity, and 3)Private activity. For class activities, once a class is created, adefault class activity will be created with the same name as the classname.

ActivityLog

The system may maintain various logs. For instance, an “activitylog”table 262 may record the ID of log items along with a category and themessage to be logged.

Signup (Parent is Activity):

The system may provide the ability to create signup sheets for variousactivities. A “signup” table 262 may comprise rows recording a name, adescription, a user ID of the creator if the signup entry, an itemsequence, a type, a status, an indicator of whether the signup isswappable, an indication of whether the signup is multi-signable, an IDof the parent activity, and a theme.

Signups may comprise one or more signup sheets for timeslots. Timeslotsmay comprise one or more signup sheets for providing items or resourcesfor an event.

Signup Timeslot (Parent is Signup)

Some signups, such as parent-teacher conferences or bake sales, mayrequire signup for specific timeslots. A “signuptimeslot” table 264 mayrecord information about available time slots, including start and endtimes, location, and a description related to the timeslot. Each signupmay have one or more signup timeslots, and each timeslot may have zeroor more signup items. A first timeslot may be automatically created bythe system.

Signup Item (Parent is Signup Timeslot)

A “signupitem” table 266 may record the ID, name, description, desiredquantity, and type of items needed for an event. For scenarios like aparty, the signup may have one timeslot with all signup items belong tothat timeslot. For a parent-teacher conference, there may be multipletimeslots, and each timeslots, with each timeslot having only have onesignup item. For some volunteer situations, there may be multipletimeslots, with each timeslot need multiple items (e.g., parents).

Swap

The system may accommodate user requests to exchange or swap commitmentsto timeslots or items. In a preferred embodiment, a “signupswap” table268 is used to record information regarding requested swaps. Each rowcomprises an ID of the swap, an ID of the user currently signed up forthe spot, an ID of the user requesting the spot, a time of modification,and a status.

Notes and Announcements

In a preferred embodiment, announcements can be easily published todifferent groups, such as a school or a class. An “announcement” table270 may be used to store information regarding the announcements. Eachrecord may comprise a title, the body of the announcement, the ID of theuser who created the announcement, and the ID of an attachment.

Teachers can create school/classroom notes for parents. Notes can bepublished to multiple classrooms. A user in the school administrator cancreate school-wide announcements. Fields for entry of notes andannouncements preferably allow entry of rich text.

School Forum

In addition to the classroom discussions, a school-level forum may alsobe provided. All topics can be discussed at school level and all parentsin the school can participate. Attachments can be embedded in thediscussions.

School Directory

A school directory is provided with a live listing of all usersassociated with the school. Individual users with associations withmultiple classrooms may appear multiple times in the directoryassociated with each of those classrooms. A school administrator maybulk create school parent directory. The directory may be exported in aform such as Microsoft Excel.

Post/Comments

Activities may have associated posts. A “post” table 274 may record ID,subject, and body of the post, the ID of the user making the post, andthe ID of the parent activity. Users may add comments to “posts.”

A “comment” table 276 may record the ID and body text of a comment, aswell as the user ID of the user making the comment.

Album/Image

Activities may have associated albums of photos. An “album” table 280may record information related to these albums. Each row may comprise anID of the album, the ID of the activity to which the album isassociated, a title for the album, the user ID of the user who createdthe album, and the ID of the parent activity.

An “image” table 282 may then store information regarding photosassociated with each album. Each row of the table may comprise an imageID, the ID of the album to which the image belongs, a caption, anindicator of image type, and the ID of the user who added the image tothe album.

Attachment (Parent is Activity)

The system may provide the ability to add attachments related toactivities. An “attachment” table 286 may store information related tothese attachments. Each row may comprise an ID of the attachment, an IDof the activity to which the attachment is associated, a description, aname, a key, and a user ID of the creator of the attachment. The key maybe an identifier allowing access to the attachment data in a local orremote storage. In a preferred embodiment, attachment data is stored inAmazon S3 storage and the key is an Amazon S3 key for the stored file.

Event (Parent is Activity or User)

An Event table 290 stored information related to events. Each event rowmay comprise start and end times, a title, a description, a location, anindication as to whether the event is an all day event, an indication ofthe period of recurrence of the event, a recurrence ending date,information related to a reminder, and a user ID of the creator of theevent. The event row may also comprise an ID of a parent activity oruser.

It is to be understood that while the entities and their relations havebeen described with particular names, the names themselves may varywithin the scope of the invention. It is also to be understood thatvariants of the system may utilize more or fewer tables than thosedescribed. For instance, certain instances of the system may omitfunctions such as photo sharing, with the relevant tables being eithernot present or not utilized.

Features

The system provides a wide variety of features and functions associatedwith the data entities described above. Access to these features andfunctions is preferably restricted to authenticated users.

FIG. 3 is an exemplary login screen for the communication andcollaboration system 100. The login screen may be presented to a user,for instance, at a computer 110, 112, 114, or at a mobile device servicethe same role. Portions of the user interface 300 are provided for entryof an email address or username 310, entry of a password 320, initiatinglogin 330, requesting or resetting a password, or signing up for anaccount 350. It is to be understood that while a login screen has beendescribed, other access control mechanisms known in the art may also beutilized within the scope of the system.

Calendar

In a preferred embodiment, three types of calendars are provided: Schoolcalendar, Group calendar, and Personal calendar. The user may beprovided with an overlay view of these calendars. Activities,invitations, and sign-ups with time information will be automaticallyadded to a school, group, or personal calendar upon creation. Emailreminders may be sent to parents prior to events, if configured by thecreator of the calendar event.

FIG. 4 is a calendar interface of a communication and collaborationsystem of FIG. 1. User interface elements preferably include elementsfor selecting the type of calendar 410, for viewing the calendar 420,and for viewing and selecting events on the calendar 430.

EXAMPLE

The purposes and relationships between the various tables of thedescribed database schema may be clarified through discussion of anexample usage scenario.

After an administrator logs in, the system may query school and schoolyear tables by school ID and current school year and return the relevantschool information. The administrator provides information for creationof a registration for a session, such as “summer camp,” for the relevantschool and school year. The system then inserts a record into the CourseRegistration table.

The administrator then provides input regarding a course, such as “chessclub,” to be added to the “summer camp” session. Upon submission of theclass data, the system inserts the data into the Course table withreference to the registration “summer camp”.

Later, a parent user may log in. The parent is presented with availableregistrations for the school ID with which they are associated, such asthe newly created “summer camp.” That is, the “summer camp” registrationis displayed by the system to the parent because this parent is anactive member of the school for the current school year. Thisrelationship is determined using data from the SchoolUser table.

The parent adds his child to his profile by entering information aboutthe student, causing the system to create a record with the informationin the Student table with reference to the parent user ID. If the parentenrolls a student in the “chess club” class, the system records thisenrollment by associating and inserting his child ID and the course IDinto the CourseRegistration table. After a parent pays the tuition, thesystem activates his child or student as an active member of this class.

The system also creates a dynamic group for this class roster for “chessclub” with reference to the Course ID. This group dynamically displaysthis group to parents of students in the associated course. Parents mayselect this group, post a discussion topic, post comments to otherparents' topics. The system creates post records in a Post table withreference to the group ID.

Parents may also create photo albums and upload photos for sharing. Thesystem creates photo records in an Album table with reference to theGroup ID. Parents may also upload documents for sharing, which arereferenced in an Attachment table, again with reference to thecorresponding Group ID.

Teachers associated with a group may publish class notes and forms to agroup, which may be referenced in records of an Announcement table withreference to the group ID. A teacher may create a sign-up, such as“chess club volunteer sign-up.” The system will create a signup recordwith reference to the “chess club” group ID in a Signup table. Parentsassociated with the Group may then be presented with a user interfaceallowing them to sign up. Upon entry of required information by theparent, the system insert a sign-up record into the UserSignup table,associating the signup ID and the parent ID.

The teacher creates an invite, such as “celebration party,” withreference to the “chess club” group ID, the record is created inInvitation table. Parents accept the “celebration party” using the userinterface and the system inserts a record into the UserSignup tableassociating the corresponding invite ID and parent ID.

User Interface

FIG. 5 is an exemplary user interface 500 for presentation of a schoolactivity. The user interface provides access to appropriate school 510,class 520, and private 530 activities for the user. In a preferredembodiment, a dashboard view for a particular activity presents a nameand description of the activity 540, discussion 550, photos 560,documents 570, signups 580, and invitations 590 associated with theactivity on a single screen for easy access. Individual tabs fordiscussion, photo, attachment, forum, signup, and invitation, maypresent only that portion of information related to the activity.

FIG. 6 is an exemplary user interface 600 for interaction with a classactivity. The user interface provides access to appropriate school 610,class 620, and private 630 activities for the user. In a preferredembodiment, a dashboard view for a particular activity presents a nameand description of the activity 640, discussion 650, photos 660,documents 670, signups 680, and invitations 690 associated with theactivity on a single screen for easy access. Individual tabs fordiscussion, photo, attachment, forum, signup, and invitation, maypresent only that portion of information related to the activity.

FIG. 7 is an exemplary user interface 700 for the discussion tab of anActivity. User interface 700 preferably comprises interface elements forpresenting the name or other identifying information related to theActivity 710, selecting tabs for items relevant to the Activity 720, andentering messages 730, as well as for presenting the messages themselves740, presenting comments related to the messages 750, and for enteringcomments related to the messages 760.

Registration Process

A user in an administrator role may create “registrations” associatedwith an education period such as a course, semester, or school year. Aregistration may comprise, for instance, a single class, all of theclasses for a particular semester, or a school year. Once a registrationhas been created, users may register for classes for the associatedsemester or school year.

FIG. 8 is an illustration of an exemplary user interface 800 forcreating a new course registration. The administrator creating thecourse registration may be provided with a user interface 800 with entryfields, for instance, for the name of the course 810, registration startdate 820, class start date 830, payment options 840, open seat displayoptions 850, discount options 860, course description 870, restrictionson who may register 880, and registration deadline 890. A submissionbutton 895 may be provided for submission of the course registrationinformation.

As shown in FIG. 9, the administrator may then use user interface 900 toadd individual classes or courses 920 associated with the registration910. In a preferred embodiment, for each class, fields 950 are providedfor the entry of a class name, class description, room, date and time,number of seats available for registration, teacher, tuition amount, andnotes. The fields to be presented may be configured based upon theregistrations policies and nature of the school. A function maypreferably be provided to copy all class names from a prior school yearto the new school year, which may then be edited by the administrator. Asubmission button 990 is preferably provided to allow the user toindicate when all data has been entered and the new class should beadded.

FIG. 10 shows an example of a listing of courses after entry of datainto the form of FIG. 9. The user interface 1000 preferably displays aname and description 1010 for the selected registration, information1020 regarding relevant dates for the registration, a user interfaceelement for adding an additional class to the registration 1030, fee anddeadline information 1040, and a listing 1050 of information regardingthe existing classes for the registration. The user interface elementfor adding classes 1030 may bring the user to a user interface such asthat of FIG. 9. A user interface element 1070 may be present for eachlisted class to allow viewing of the roster. Another user interfaceelement 1060 may be present for providing a combined list for allclasses associated for the registration. In a preferred embodiment, astudent registered for multiple classes may appear multiple times in thelist of registered student with separate statuses, such as paymentstatus, listed for each class.

After an administrator has created the registration, parents or studentsmay then, after the registration start time, sign up. In the presentexample, the user of the system is a parent or guardian registering astudent. However, it is to be understood that the system may be adaptedto allow students themselves to act as users in appropriateenvironments.

FIG. 11 is an illustration of a registration form 1100 for studentregistration. In this example, the user is a parent with two studentsenrolled at the school. The user interface form 1100 preferably displaysinformation regarding the name of the registration 1120, informationregarding the registration 1150 such as a description and relevant datesand deadlines, and information regarding registration fees 1160.

Courses associated with the selected registration are displayed to theuser in a list 1170. Course listings are preferably accompanied bybuttons allowing the user to sign up, or in the case of a class that hasalready reached its enrollment limit, add the user to a waiting list. Inthis example, separate checkboxes are provided for each of the twostudents associated with the user, allowing simultaneous registration ofboth students for classes in the 2014 Fall After School Registration.

FIG. 12 is an exemplary user interface 1200 for entry of informationregarding the user and associated students. The user interfacepreferably provides input fields 1210 for information related to theparent/guardian user, input fields for health and emergency contactinformation 1240, and input fields for information 1270 regarding thestudents associated with the user. The interface further provides a userinterface element for adding additional students 1275.

FIG. 13 is an illustration of a confirmation screen 1300 presented afterthe user has selected the signup button associated with a course. Theconfirmation screen 1300 preferably comprises information regarding theregistration session 1310, information regarding the class or classesfor which the student is being registered 1330, and fee information1350. Information 1330 preferably comprises details of the course thatwas selected and a user interface element to allow the course to beremoved.

FIG. 14 is an illustration of an order history display 1400. In apreferred embodiment, the order history display 1400 may be presentedwith the user interface 1300 of FIG. 13. Display 1400 preferablycomprises information regarding order data 1410, order number 1430, theclass registration 1450, including an indication of student, paymentstatus and amount due 1470, and user interface elements for initiatingpayments using one or more payment mechanisms 1490.

After registration is complete, the system may product or present aclass registration summary and signature form. The form preferablycomprises information about the student's course selections andbiographical information. The form may also optionally comprise asignature block for use in environments where a signed paperconfirmation is required from the student.

After sign up, the administrator will have a view of all students forthat class, with a dropdown to indicate paid or unpaid status. Once theadministrator selected “paid,” the administrator can enter a checknumber to that row. The user confirmation page for that user will changethe course registration status from pending to complete.

As users register, or after the completion of the registration period,the administrator may generate a comma-separated-value (CSV) or otherreport listing the registered users and their sign-up information, whichcan be passed to other entities such as an accounting department.

Conclusion

It will be appreciated by those skilled in the art that changes could bemade to the embodiments described above without departing from the broadinventive concept thereof. It is understood, therefore, that thisinvention is not limited to the particular embodiments disclosed, but itis intended to cover modifications within the spirit and scope of thepresent invention as defined by the present disclosure.

We claim:
 1. A method of facilitating communications using acommunications system comprising a database storing database table data,a processor for executing program code, and a network connection forsending and receiving data, comprising: receiving, over the networkconnection, information from an administrator user regarding aregistration session; adding a first registration session record to aregistration session table stored in the database, the firstregistration session record comprising a first registration session ID;receiving, over the network connection, information from anadministrator user regarding a first course associated with the firstregistration session; adding a first course record to a course recordtable, wherein the first course record comprises a first course ID andthe first registration session ID; adding a first group record to agroup table, wherein the first group record comprises a group ID and thefirst course ID; causing display of a list of courses associated withthe first registration session, including the first course, to each of aplurality of non-administrator users; receiving, over the networkconnection, information from each non-administrator user of theplurality of non-administrator users regarding a student registrationfor the first course; for each student registration for the firstcourse, adding a student course registration record to a student courseregistration table, wherein the student course registration recordcomprises a student ID associated with the student registration and thefirst course ID; and for each student registration for the first course,adding a group user record to a group user table, wherein the group userrecord comprises the first group ID and a student ID for the student. 2.The method of claim 1, further comprising: validating first logininformation associated with a first user ID, wherein the logininformation is received from a first user over the network; performing adatabase query to determine a list of group records in the group tableassociated with a student ID associated with the first user ID; andcausing the display of information regarding at least one groupassociated with at least one of the group records from the list of grouprecords to the user associated with the first user ID.
 3. The method ofclaim 2, further comprising: receiving information from the first userrelated to a post related to the at least one group associated with atleast one of the group records from the list of group records to theuser; creating a first post record in a post table, wherein the postrecord comprises the first user ID, a first post ID, and either thegroup ID of the at least one group or an activity ID of an activityassociated with the at least one group.
 4. The method of claim 3,further comprising: validating first login information associated with asecond user ID, wherein the login information is received from a userover the network; performing a database query to determine a list ofgroup records in the group table associated with a student ID associatedwith the second user ID, wherein the list of group records in the grouptable associated with a student ID associated with the second user IDcomprises the at least one group associated with at least one of thegroup records from the list of group records associated with the firstuser ID; and causing the display of information regarding at least onegroup associated with at least one of the group records from the list ofgroup records to the user associated with second user ID, where in theinformation comprises information from the first post record.
 5. Themethod of claim 3, further comprising: performing a database query todetermine a list of user IDs associated with the group ID associatedwith the group with which the first post record is associated; andtransmitting a notification to an address associated with each user IDin the list of user IDs, the notification comprising information relatedto the post associated with the first post record.
 6. The method ofclaim 5 wherein the notification is one of an email, an SMS message, asocial media message, or an application notification.
 7. The method ofclaim 5 wherein the address is one of an email address, a phone number,an IP address, or a mobile device identifier.
 8. The method of claim 2,further comprising: receiving information from the user related tocreating a first signup related to the at least one group associatedwith at least one of the group records from the list of group records tothe user; creating a first signup record in a signup table, wherein thesignup record comprises the first user ID, a first signup ID, and eitherthe group ID of the at least one group or an activity ID of an activityassociated with the at least one group.
 9. The method of claim 8,further comprising: validating first login information associated with asecond user ID, wherein the login information is received from a userover the network; performing a database query to determine a list ofgroup records in the group table associated with a student ID associatedwith the second user ID, wherein the list of group records in the grouptable associated with a student ID associated with the second user IDcomprises the at least one group associated with at least one of thegroup records from the list of group records associated with the firstuser ID; and causing the display of information regarding at least onegroup associated with at least one of the group records from the list ofgroup records to the user associated with second user ID, where in theinformation comprises information regarding the first signup.
 10. Themethod of claim 9, further comprising: receiving information from thesecond user indicating selection of a user interface element for sign upfor the first signup; creating a user sign up record in a user signuptable, wherein the user signup record comprises the second user ID andthe first signup ID.
 11. The method of claim 2, further comprising:receiving information from the first user related to an album related tothe at least one group associated with at least one of the group recordsfrom the list of group records to the user; creating a first albumrecord in an album table, wherein the album record comprises the firstuser ID, a first album ID, and either the group ID of the at least onegroup or an activity ID of an activity associated with the at least onegroup.
 12. The method of claim 11, further comprising: creating a firstphoto record in a photo table comprising a first photo ID and the firstalbum ID.
 13. The method of claim 2, further comprising: receivinginformation from the first user related to an event related to the atleast one group associated with at least one of the group records fromthe list of group records to the user; creating a first event record inan event table, wherein the event record comprises the first user ID, afirst event ID, and either the group ID of the at least one group or anactivity ID of an activity associated with the at least one group. 14.The method of claim 2, further comprising: receiving information fromthe first user related to an attachment related to the at least onegroup associated with at least one of the group records from the list ofgroup records to the user; creating a first attachment record in anattachment table, wherein the attachment record comprises the first userID, a first event ID, and either the group ID of the at least one groupor an activity ID of an activity associated with the at least one group.